pp108 : Runtime Behavioral Exceptions in the Organization Space

Runtime Behavioral Exceptions in the Organization Space

This topic lists the exceptions that arise during run time in the Organization space.

Documents that do not support deployment to the Organization space

All artifacts are not organization aware. If an application package is being deployed in the Organization space, which contains an artifact that does not support organization level deployment, the deployment action will fail with an appropriate error message. Ensure that you structure your CWS project content and package the content accordingly.

The following artifacts do not support deployment to the Organization space:

  • Object Template
  • File
  • Jar files

Documents and exceptions

The following table lists the runtime exceptions that may arise per artifact in the Organization space:

Document

Exception Scenario

User Interface Delivery Model

  • If tasks were already delivered to the Inbox, then the delivery model used for task delivery will not be deleted when the related application package is uninstalled. In cases where an application package is uninstalled from the Organization space and deployed newly into the Shared space, you may notice that new tasks being delivered to the organization still use the delivery model remaining in the organization.

Work List

  • Work lists are internally identified by GUIDs. If the same work list is deployed in both the Organization space and Shared space, and the name of the work list in the Organization space has been modified, then the users in the organization who are a part of the work list still see the name of the work list that is deployed in the Shared space. This issue occurs only when a work list with the same name is deployed in both the Organization space and Shared space. If any other customization is made to the work list in the Organization space, the users who are a part of that work list will see the customized version only.

Organization Unit

  • Organization units (also called teams in run time) are identified primarily by GUIDs. When two organization units with different IDs and the same name are deployed in two different spaces, namely Shared space and Organization space, an administrator can view both through the User Manager. Multiple teams with the same name can also be seen in the User Manager when organization units with the same name and different IDs are available in the organization.
  • If an organization unit is referred in a process (BPM model) with a fully qualified name, and if multiple organization units are available in an organization such as in the scenario explained above, then that task delivery is not always guaranteed to happen to a specific organization unit.
  • When an application having the organization unit is upgraded with a change in the name, then the reload of the existing runtime reference over that organization unit fails. This failure is caused as the runtime reference of the organization unit is based both on the GUID and the fully qualified name of the organization unit. It is suggested that users delete such references and create new references.
  • When an organization unit is customized, for example, through a change in the association of the roles and deployed, then you must update the user mappings through the User Manager accordingly. When such customized content is deployed, the User Manager shows the earlier mappings until the time they are updated to reflect the new changes deployed. Unless you update the mappings, scenarios such as escalations over tasks delivered based on the earlier mappings do not work as expected. Once the mappings are updated, all the scenarios work as expected. Such user mappings are required to be updated whenever any change is introduced to the organization units. Such a change is possible due to one of the following reasons:
    • When an application upgrade is taken up with the changes in the organization unit
    • Due to deployment of the customized content into the Organization space
    • When modified content is published into an organization

Rule

  • If a rule is deployed in the Shared space as well as in the Organization space and the rule deployed in the Organization space expires, when the rule is triggered from this organization, the rule present in the organization is ignored as it is expired and the one present in the Shared space is triggered.
  • In the Deployed Rules user interface, even if a rule published to the Shared space is explicitly selected for execution, the organization level rule is always executed.

File

  • Files can only be deployed to the Shared space and not to the Organization space.

Java Archive

  • Java archive files (.jar) can only be deployed to the Shared space and not to the Organization space.

MDM Model

  • You cannot deploy the same MDM application model to the Shared space as other tenants are pointing to the same application databases. In scenarios where there is a need to deploy the same MDM application model for multiple tenants, ensure that the application databases are different for each deployment.
  • You cannot perform concurrent upload or download operations in multiple organizations on an MDM Model deployed in the Shared space.

Schedule

  • Schedules, which are deployed into the Shared space through ISVP or CAP cannot be instantiated and consumed in more than one organization. Schedules available in the organizations can be instantiated by the users of that organization only. If the same schedule is required in multiple organizations, then it must be packaged and deployed in those organizations. Schedules deployed to specific organizations can be instantiated by the users of that organization.

KPI

  • The trend for a KPI that is deployed in Shared space is possible to be worked upon only in one organization. As the deployment of the schedules at the shared level can only be triggered in one organization, users must manually instantiate the schedule in the organization in which the trend generated by the KPI is required to be viewed.
  • After deploying the KPIs containing the e-mail models to the organization space, the e-mail model Web services must be attached to the notification service container in that organization.

Business Event Response (BER)

  • After deploying the BERs containing the e-mail models to the Organization space, the e-mail model Web service must be attached to the notification service container in that organization.

Process Monitoring Object (PMO)

  • When ever a BPM model is modified and deployed into an organization, the related PMOs must be also modified and deployed into the organization.

Web Service Interface

  • Two different CAPs having two different Web service interfaces with the same name cannot be deployed in the same organization.The loading of the second CAP fails to insert the Web service interface as another Web service interface with the same name is already available in LDAP (deployed through the first CAP). 
  • If a Web service interface with the same name exists in the organization space and shared space, the one in the organization space is considered first. In this case, the runtime referenced Web service interface name matches that of the existing Web service interface in the organization space. The Web service interface can be deployed to the organization space through a CAP or published from CWS design-time.

Business Calendar

  • When a customized business calendar is deployed into an organization, the reload of the existing runtime reference over the artifact does not indicate that the binding is now updated to what is deployed to the organization. This behavior does not impact the runtime execution behavior. When executed, if the organization version is available with the name being referred, then only the organization version is considered for execution.

 

Other exceptions

Following are the other issues that are not specifically related to a document but can be associated to an execution behavior. These are mentioned component-wise to help you relate them easily.

 

Component

Exception Scenario

BPM

  • Process documentation configuration is not organization specific.
  • Calls to the custom Java methods using XPaths in the BPM models do not use organization-specific jar files.
  • Direct instantiation of process models from Deployed Process Models, which are deployed directly into an Organization space and which consume Web services that are deployed into the Shared space will not work as expected. Instantiation of such models by any other means will work.

Case Instance Manager

  • There is only one case model shown even though the model is deployed to both the Shared and the Organization spaces.
  • Instances in the detail view are only shown for a single case model (though instances exists for the system model and the organization model).

Schedule Manager

  • Schedules deployed to both Shared and organization of a single schedule are shown in the Inactive Schedules tab of the Schedule Manager.
  • For the scenario mentioned above, if the schedule of the Organization space is deployed, then the schedule deployed to the Shared space is also hidden.

BAM

  • The BAM service container is required in the organization to work with BAM.
  • All the BAM service containers in the Process Platform instance must always point to the same repository.
  • BAM content must not be spread between the Shared space and the Organization space. To work with BAM in an organization, content must be installed completely in that organization.

Web Service Interface

  • It is possible to deploy the Web service interface or method set on the organization level, but it cannot be linked to a service group, which is defined at the system level.